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1 Introduction 

In this technical report wc describe describe the Domain Specific Language (DSL) of the 
Workflow Execution Execution (WEE) introduced in [1, 2]. Instead of interpreting an XML 
based workflow description language like BPEL, the WEE uses a minimized but expressive set 
of statements that runs directly on to of a virtual machine that supports the Ruby language. 
Frameworks/ Virtual Machines supporting supporting this language include Java, .NET and 
there exists also a standalone Virtual Machine. 

Using a DSL gives us the advantage of maintaining a very compact code base of under 400 
lines of code, as the host programming language implements all the concepts like parallelism, 
threads, checking for syntactic correctness. The implementation just hooks into existing 
statements to keep track of the workflow and deliver information about current existing 
context variables and state to the environment that embeds WEE. 

2 Domain Specific Language 

The DSL to describe a workflow consists of a minimal vocabulary. In this section we want 
to describe the elements of the vocabulary in conjunction with a simple example (see Listing 
1): a flight as well as a hotel have to be booked for three people. If the payed sum for 
all three people exceeds 10000 credits an external entity is informed. The set of available 
DSL-elements is: 

activity is an atomic operation and executes a specific task. We distinguish between 
two types of activities: manipulate- activities (see line 40) are simple operations that 



are executed within the WEE. The intention is to provide an easy way to perform 
calculations or context changes, call- activities (see line 21) are used to carry out more 
complex tasks which are encapsulated in any kind of service. The execution of a call- 
activity is delegated to the handler wrapper. Therefore it is irrelevant if the service is 
a webservice or any other kind of service. The handler wrapper is provided with the 
location of the service (i.e. an endpoint) and optional parameters. 

parallel defines two or more parallel branches which are executed concurrently (see line 
18). Each branch is executed in a separated thread but they still share the context 
of the workflow. We distinguish between two variants of parallel execution. First, the 
wait-variant is on hold until each branch has finished before the thread of control is 
passed to the subsequent branch. Second, the nowait-variant waits for a given amount 
of branches to be merged. Other branches who are not finished are informed to stop 
execution and are no longer executed by the WEE. The nowait-variant implements a 
kind of race between the branches to finish. It can be used to start different approaches 
to finish a job, but continues as soon as any result is available. 

choose defines a decision in the control flow (see line 44) . Multiple or none of the available 
alternative's (guarded by a condition as shown in line 45) can be chosen. Also, an else- 
path is provided by the otherwise-keyword 

cycle enables top-controlled loops (see line 17). 

critical implements the critical section pattern (see line 20). A codeblock encapsulated 

in the critical-keyword is defined to be protected by a semaphore. In a multi-threaded 
environment, a critical section ensures exclusive execution. If a thread enters execution 
of a critical section, all other threads that want to enter this section have to wait until 
the first thread has exited the critical section. Each critical section is defined by a 
symbolic name. Forming multiple codeblocks labeled with the same symbolic name 
enables critical sections to span over different parts of a workflow. 

In addition to the control structures we also defined keywords for special workflow purposes. 

These keywords are: 

handler defines which handler wrapper should be included (see line 2). 

endpoint defines the location of a service, i.e. an URI of a webservice (see line 4). 
Endpoints are provided to the handler wrapper if an external service has to be invoked. 

context defines context variables of a workflow (see line 10). Each of the context variables 
is supervised by the execution engine. 

LISTING 1: Example Workflow 

1 class Workflow < Wee 

2 handler MyHandler 
3 

4 endpoint : epAirBook => " uri : air /booking" 

epHotelBook => " uri : hotel /booking" 
epAirPay => " uri : air /payment" 
epHotelPay => " uri : hotel /payment" 
epinform => " uri : company/inform" 
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5 endpo 

6 endpo 

7 endpo 

8 endpoint 
9 

10 context : persons => 3 

11 context : creditcard => "Visa_12345" 



2 



12 context : airline => nil , : hotel => nil 

13 context : from => "Vienna", :to => "Prag" 

14 context : sum => 
15 

16 control flow do 



17 cycle ( ©persons > 0) do 

18 parallel (: wait ) do 

19 parallol_branch do 

20 c r i t i c a 1 ( : airbooking ) do 

21 activity : bookFlight , : call , epAirBook , ©from, @to do | id | 

22 ©airline = id 

23 end 

24 activity : payFlight , : call , epAirPay , ©airline, ©creditcard do | amount | 

25 ©sum += amount 

26 end 

27 end 

28 end 

29 parallel_branch do 

30 cr i t ical ( : hotelbooking ) do 

31 activity : bookHotel , : call , epHotelBook , ©to do | id | 

32 ©hotel = id 

33 end 

34 activity : payHotel , : call , epHotelPay , ©hotel, ©creditcard do | amount | 

35 ©sum += amount 

36 end 

37 end 

38 end 

39 end 

40 activity : countdown , : manipulate do 

41 ©persons — = 1 

42 end 

43 end 

44 choose do 

45 alternative (©sum > 10000) do 

46 activity : inform , : call , epinform , ©sum 

47 end 

48 end 



49 end 

50 end 



3 Evaluation 

In this section we try to evaluate the coverage of possible workflow control structures with 
our basic set of DSL elements. We choose the workflow patterns repository by Van der Aalst 

ct al. [3] as starting point to validate our prototype. The control flow patterns focus on the 
dependencies between multiple activities and branches of a workflow. 

Each pattern can be supported by our execution engine in one of four different ways which 
arc ordered by degree of support: 

directly supported: The pattern is supported by an explicit language element in the ^9 

WEE-DSL or a simple combination of them. 

modified worlcfiow: The pattern can be expressed by rearranging existing elements. ^ 
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This is possible if the behaviour of the pattern can be imitated through the composition 
of other patterns that are implemented by the WEE. 

* handler /external: The pattern can be implemented in cooperation with an adopted 

handler wrapper or other external modules. These modules are still orchastrated by 
the WEE through the worfklow description but contribute the actual logic how to 
implement the pattern in coordination with the WEE. 

X orchestrated instances: The pattern can only be expressed by controlling multiple 
instances of the execution engine. In addition, these instances have to be orchestrated 
and managed by the controller of the instances (e.g. the controller is responsible for 
data exchange between the instances). As the controller has the control about each 
instance, the orchestration can be itemized down to the execution of single activities. 
Of course, the pattern is then not implemented by the WEE, the logic is mainly within 
the controller. 

3.1 Basic Control Flow Patterns 

Each of the basic control flow patterns is directly supported by an explicit WEE-DSL element. 

Z'Z> Sequence. The sequence pattern indicates that an activity is started after another ac- 
tivity finishes. An example implementation can be seen in Listing 2. 

LISTING 2: Sequence pattern 

1 activity : al , : call , endpointl 

2 activity : a2 , : call , endpoint2 

W Parallel split &i Synchronization. The parallel split generates multiple branches which 
have to be executed concurrently. The synchronization merges this branches together 
as soon as all parallel branches have finished. Listing 3 shows the implementation in 
the WEE-DSL. 

LISTING 3: Parallel split & Synchronization 

1 parallel : wait do 

2 parallel-branch do 

3 activity : branchl.al , : call , endpointl 

4 end 

5 parallel-branch do 

6 activity :branch2_al, : call , endpoint2 

7 end 

8 end 

Z''^ Exclusive Choice & Simple Merge. Exclusive choice selects one of multiple possible 
Cv* branches to be executed. Which branch to continue on is decided by a condition. The 

simple merge joins multiple branches into a single subsequent branch. The subsequent 
branch is executed as soon as one of the multiple branches has finished. The implemen- 
tation of these two patterns can be seen in Listing 4. Multiple branches can be defined 
by the keyword alternative. Each alternative is guarded with a condition that indicates 
in which situation the branch should be executed as indicated in line 3. If none of the 
defined alternatives is executed, the optional otherwise-section is executed as indicated 
in line 6. 
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LISTING 4: EXCLUSIVE CHOICE & Simple Merge 

1 context : x => 5 

2 choose do 

3 alternative (@x > 1) do 

4 activity : alternativel_al , : call , endpointl 

5 end 

6 otherwise do 

7 activity : alternative2_al , : call , endpoint2 

8 end 

9 end 



3.2 Advanced Branching and Synchronization Patterns 

Multi-Choice, Multi-Merge & Structured Synchronizing Merge. The multi- W 
choice pattern extends the exclusive choice pattern by allowing multiple branches to ^ 
be executed. The merge of these branches therefore has to merge one or more pos- 
sible branches. The WEE-DSL does not distinguish between these patterns and the 
exclusive choice & the simple merge pattern. An example of a multi-choice with two 
executed branches can be seen in listing 5. The alternatives in line 3 and line 6 are 
both executed in this example. In this case the branches are not executed concurrent 
but one after another. Listing 6 shows an example how to implement the patterns 
to execute the branches concurrent which results in a structured synchronizing merge. 
Each paralleLbranch-hlock is executed in a separated thread. To indicate which threads 
are running parallel, a para//e/-block has to enclose the choice-hlock. The multi-merge 
pattern distinguishes from the structured synchronizing merge by keeping the multiple 
threads of control beyond the merging point. If the multi choice pattern results in the 
execution of two or more branches, each thread of control is passed to the subsequent 
branch in the way that the subsequent branch is executed two or more times. The multi 
merge pattern is not supported by the WEE. 

LISTING 5: Multi-Choice & Structured Synchronizing Merge - Not con- 
current 

1 context :x => 5 

2 choose do 

3 alternative (@x > 1) do 

4 activity : alt ernat i ve 1 _a 1 , : call , endpointl 

5 end 

6 alternative (@x < 10) do 

7 activity : alternative2_al , : call , endpoint2 

8 end 

9 otherwise do 

10 activity : alternative3_al , : call , endpoint3 

11 end 

12 end 

LISTING 6: Multi-Choice & Structured Synchronizing Merge - Concurrent 

1 context :x => 5 

2 parallel do 

3 choose do 

4 alternative (@x > 1) do 

5 parallel_branch do 

6 activity : alternativel _al , : call , endpointl 
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7 end 

8 end 

9 alternative (@x < 10) do 

10 parallcl_branch do 

11 activity : alt ernat i ve2 _a 1 , : call , endpoint2 

12 end 

13 end 

14 otherwise do 

15 parallel .branch do 

16 activity : alternative3_al , : call , endpointS 

17 end 

18 end 



19 end 

20 end 

Structured Discriminator. The structured discriminator pattern is similar to the struc- 
tured synchronizing merge pattern. While the structured synchronizing merge pattern 
is used to join branches forked by a choice, the structured discriminator merges branches 
forked by a parallel split. Also, the structured discriminator does not wait until each 
branch finished but continues the subsequent branch as soon as one branch finishes. 
Other parallel branches may be still executed and are terminated as they approach at 
the structured discriminator. The structured discriminator is not supported directly in 
the WEE-DSL. However, the structured discriminator has two variants. 

The Blocking Discriminator pattern does not allow to fork parallel branches while an- 
other instance is still executing one of the branches. As the WEE focuses on the exe- 
cution within one workflow instance, it does not support interactions or management 
between multiple instances. Therefore, this pattern is not supported. 

The Canceling Discriminator pattern passes the thread of control to the subsequent 
branch as soon as one of the parallel branches has finished. All remaining parallel 
branches that are still executed are canceled. The WEE-DSL supports this pattern 
by providing a parameter to the parallel-block as can be seen in listing 7. The wait- 
parameter can be used to set how much branches have to be finished before the execution 
in the subsequent branch is continued. The no-longer-necessary-signal is sent to still 
running branches, urging them to quit execution. 

LISTING 7: Canceling Discriminator 

1 parallel : wait => 1 do 



2 parallcl_branch do 

3 activity :branchl_al , : call , endpointl 

4 end 

5 parallel_branch do 

6 activity :branch2_a2, : call , endpoint2 

7 end 



8 end 

Structured Partial Join. The structured partial join pattern is similar to the struc- 
tured discriminator but continues the subsequent branch as soon as a specified amount 
of branches finishes execution. As the WEE-DSL uses the same constructs for the Dis- 
criminator, the structural partial join and its variant, the Blocking Partial Join are not 
supported. The Canceling Partial Join works as a generalized version of the canceling 
discriminator, therefore the listing 7 shows both patterns. 
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Generalised AND-Join. The generalised AND-join pattern merges branches as soon as x 
all incoming branches have been completed. In contrast to the synchronization pattern, 

the generalised AND-join supports the join across multiple threads of controls and 
passes the thread of control to the subsequent branch each time all incoming branches 
are completed. This is also true even when the parallel branches are not created by the 
same parallel split event. The WEE does not support the generalised AND-join pattern 
as it is only able to merge branches that result from the same parallel split event. 

Local Synchronizing Merge & General Synchronizing Merge. These two patterns x 
can be used instead of the synchronization if the process description is not structured. ^ 
Both patterns are able to pass the thread of control to the subsequent branch if all 
branches are executed or if it is sure that all outstanding branches are not going to 
arrive at the merge point. Other than in the local synchronizing merge situation, the 
information if branches are going to arrive at the merge point is not available locally 
in the general synchronizing merge situation. This information may be gathered by 
the evaluation of possible prospective states of the executed branch. Both patterns 
cannot be translated into the WEE-DSL as the process definition is expressed in a 
block oriented manner. Therefore, the process description is available in a structured 
way which conflicts with the basic reason for the two patterns. 

Thread Split &; Thread Merge. The thread split pattern generates a specific amount of W 
threads. Each of the threads executes the subsequent branch. The thread merge pattern 
is able to merge multiple thread that arc generated by the thread split pattern. The 
pattern description states that the number of threads that have to be generated must be 
specified at design-time. Although the concepts of threads within a workflow instance 
was not intended in the design of the WEE-DSL apart from parallel branches, the 
dynamic generation of threads can be achieved by cascading the paralleLbranch-element 
into a loop (cycle-clcmcnt) . As each paralleLbranch forks a thread, this arrangement 
implements the thread-split and the thread- merge pattern through a minor modiflcation 
of the workflow. An example implementation can be seen in listing 8. 

LISTING 8: Thread-Split & Thread-Merge 

1 parallel : wait do 

2 context :x 3 

3 cycle ("@x^=„0" ) do 

4 activity : countdown , : manipulate do 

5 @x -= 1 

6 end 

7 parallel_branch do 

8 activity :a, : call , endpointl 

9 end 

10 end 

11 end 



3.3 State Based Patterns 

Deferred Choice. The deferred choice pattern chooses one of multiple possible branches 9 
to be executed. The decision, which branch has to be executed, is delayed as long 
as possible. In contrast to the choice-patterns, the decision is not made explicit by a 
condition. After one branch starts the execution, each other branch is aborted, therefore 
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the decision is more based on a race of the branches which is executed next. There is 
no exphcit element in the WEE-DSL to express the deferred choice pattern. However, 
with the implementation of the canceling discriminator, it is possible to achieve a similar 
result. A possible implementation can be seen in listing 9. Each branch is represented 
by a single activity which is part of a parallel-hlock (which in this case is a canceling 
discriminator). Line 4 and line 9 are showing the two representative activities. As soon 
as one of them completes, a context variable expressing which branch to execute is set 
(see line 5 and line 10). As the canceling discriminator aborts all other branches, the 
context variable now indicates which branch has to be executed further. The use of the 
exclusive choice pattern is now possible (see line 14). 

LISTING 9: Deferred Choice 

1 context : choice => nil 

2 parallel : wait 1 do 

3 parallel_branch do 

4 activity : represent A , : 

5 ©choice = 1 

6 end 

7 end 

8 parallel_branch do 

9 activity : representB , : 

10 ©choice = 2 

11 end 

12 end 

13 end 

14 choose do 

15 alternative ( ©choice = 1) 

16 # branch 1 comes here 

17 end 

18 alternative ( ©choice = 2) 

19 # branch 2 comes here 

20 end 

21 end 

^ Milestone. The execution of an activity is enabled as long as a specific point in the 
execution of the workflow is reached. In general, the milestone pattern needs at least 
two parallel branches. One branch marks if the milestone is reached and enables the 
execution of specific activities in the other branch(es). These activities cannot be 
executed before the milestone is reached or after the milestone is passed. The WEE 
does not provide a direct implementation of the milestone pattern. In general, two 
approaches can be used two tackle the problem: 

1. The milestone is activated by an explicit activity and deactivated by a explicit 
activity. Before an activity which is enabled by the milestone is executed, a choose- 
element checks for the activation. Listing 10 shows an example implementation. 
After activity :activate.milestone is executed (line 4), the milestone is reached, 
which is indicated by the context variable milestone. In the parallel branch, the 
activity -.enabled (line 17) is executed if the context variable milestone is true 
when the c/ioose-element is reached (line 15). The milestone is valid as long as 
the activity :keep-milestone is running (line 7). The activity :deactivate-milestone 
(line 10) resets the context variable milestone and the .-enafe/ec^-activity is not 
executed anymore. Instead, the mot-enabled-activity is called (line 20). 



call , endpointl , 1 do 
call , endpoint2 , 2 do 

do 
do 
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2. The controller of the workflow "injects" the enabled activity by restructuring the 
workflow. The workflow execution is suspended and the workflow description is 
adjusted by the enabled activity. When the milestone is expired, the workflow 
description is set back to the original. While doing this, the controller has to take 
care about all active activities and track the thread of control for each branch. In 
this scenario, the controller supervises when and how long a milestone becomes ac- 
tive. This alternative is more difficult to implement but applicable if the milestone 
logic should not be part of the workflow description. This may be true if specific 
activities should only be executed when certain technical issues are fulfilled (e.g. 
services are only temporary available or their call should be avoided normally) 

LISTING 10: Milestone 

1 context : milestone => false 

2 parallel do 



3 parallel_branch do 

4 activity : activate_milestone , : manipulate do 

5 ©milestone = true 

6 end 

7 activity : keep_milestone , : manipulate do 

8 sleep 5 

9 end 

10 activity : deactivate_milestone , : manipulate do 

11 ©milestone = false 

12 end 

13 end 

14 parallel_branch do 

15 choose do 

16 alternative ( ©milestone) do 

17 activity : enabled , : call , endpointl 

18 end 

19 otherwise do 

20 activity : not_enabled , : call , endpoint2 

21 end 

22 end 

23 end 



24 end 

Critical Section. Two or more areas of different (parallel) branches are defined to be 
prohibited to be executed at the same time for a given workffow instance. When an 
activity of a critical section is executed, that critical section has to be completed before 
the critical section can be entered again. This pattern is also commonly described as 
mutex or semaphore. The WEE-DSL has a separate element to define critical sections. 
Listen 11 shows an example of a critical section which spans over two parallel branches. 
As a critical section can span across different branches, an identifier is necessary to 
indicate the connection. 

LISTING 11: Critical Section 

1 parallel do 



2 parallel-branch do 

3 critical(:id) do 

4 activity : parallell , : manipulate do 

5 sleep 2 

6 end 

7 end 

8 end 
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9 parallel_branch do 

10 critical(:id) do 

11 activity : parallel2 , : manipulate do 

12 sleep 2 

13 end 

14 end 

15 end 



16 end 

Z''^ Interleaved Routing. A set of branches has to be executed. The branches can be 
executed in any order but must not be executed concurrently. None of the branches 
must be active as long as another branch is executed. The thread of control is passed to 
the subsequent branch when all branches (that are part of the interleaved routing) are 
finished. The WEE-DSL does not have an explicit element for the interleaved routing 
pattern. This pattern can be easily implemented by the use of the critical section 
pattern. Listing 12 shows a sample implementation. Two (initially parallel) branches 
are opened in line 2 and line 8. As the branches share a critical section, they cannot 
run simultaneously but one after another. 

LISTING 12: Interleaved Routing 

1 parallel do 



2 parallel-branch do 

3 critical(:id) do 

4 activity : branchl.taskl , : call , endpointl 

5 activity : branchl_task2 , : call , endpoint2 

6 end 

7 end 

8 parallel-branch do 

9 critical(:id) do 

10 activity : branch2_taskl , : call , endpoint3 

11 end 

12 end 



13 end 

Z''^ Interleaved Parallel Routing. The interleaved parallel routing pattern enhances the 
interleaved routing pattern by restricting the execution to the activity-level. Parallel 
branches may be active but only one activity over all branches in the interleaved parallel 
routing is executed at one time. Again, this can be achieved by the use of the critical 
section pattern. Not the critical section has to allow a "switch" in the execution of the 
parallel branches. Therefore, the critical-elements have to span around each activity 
to give activities from other branches the chance to be executed. This can be seen in 
listing 13. 

LISTING 13: Interleaved Parallel Routing 

1 parallel do 



2 parallel_branch do 

3 critical(:id) do 

4 activity : branchl_taskl , : call , endpointl 

5 end 

6 critical(:id) do 

7 activity : branchl_task2 , : call , endpoint2 

8 end 

9 end 

10 parallel-branch do 
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11 

12 
13 



critical (: id) do 

activity : branch2_taskl , : call , endpointS 
end 



14 end 

15 end 



3.4 Multiple Instances 

The multiple instances patterns are created to deal with the generation of multiple instances 
of an activity or task within a given workflow instance. The different patterns focus on aspects 
like the amount of created instances, synchronization and merging. The generated instances 
run independent and concurrent to each other but mostly need to be synchronized with the 
workflow instance when finished. The WEE basically has no concept of multiple instances 
for an activity. However, the multiple instance patterns overlaps with the thread split/thread 
merge pattern and can be expressed by them. If this is not the case, the behavior often can be 
simulated by a suitable handler wrapper implementation. As the handler wrapper is ordered 
by the WEE with the execution of an activity, the handler wrapper can spawn the needed 
amount of instances and is able to control them as long as needed. 

Multiple Instances without Synchronization. Multiple instances of an activity are * 
created but run independent from the workflow instance. The subsequent branch does 
not have to wait for the execution of the multiple instances. The amount of instances 
is not defined, consequentially the timespan in which new instances can be created is 
not defined. This multiple instance pattern cannot be expressed by the WEE-DSL. An 
adjusted handler wrapper can simulate the behavior by spawning the needed amount 
of instances in separated threads without giving the WEE notice. This solution does 
not address the problem if the workfiow instance finishes before all instances spawned 
by the handler wrapper have finished. 

Multiple Instances with a Priori Design-Time Knowledge. A number of instances W 
is created. The amount is specified at design time. The thread of control is passed to 
the subsequent path as soon as all instances have been finished. The WEE supports 

this pattern in the same way as the thread-split and thread-merge pattern. Listing 8 
therefore can also be seen as an implementation of this pattern. The context variable 
X (defined in line 2 determines the amount of created instances of the activity defined 
in line 8. 

Multiple Instances with a Priori Run-Time Knowledge. A number of instances is '^V 
created. The amount of instances is determined by the workflow logic before the flrst 
creation of an instance. The WEE supports this pattern in the same way as the thread- 
split and thread merge pattern. In contrast to the solution above, the number of created 
instances is determined by an activity. Listing 14 shows an example implementation of 
the pattern. In line 2, the context variable is initialized to a default value. The activity 
determine (line 3 to line 5) sets the number of instances that have to be created. The 
loop (line 6) then generates the multiple instances of activity a (line 11). 

LISTING 14: Multiple Instances with a Priori Run-Time Knowledge 

1 parallel : wait do 

2 context :x => 

3 activity : determine , : call , endpointl do | count | 
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4 @x = count 

5 end 

6 cycle ("@x^=„0" ) do 

7 activity : countdown , : manipulate do 

8 @x -= 1 

9 end 

10 paranel_branch do 

11 activity :a, : call , endpointl 

12 end 

13 end 

14 end 



W Multiple Instances without a Priori Run-Time Knowledge. A number of instances 
have to be created. The number of instances is not determined until the last instance has 
finished execution. The logic if more instances have to be created cannot be determined 

a priori but is derived from the execution process, resources or external services. As 
the logic of creating further instances has to be placed inside the workflow description, 
the implementation differs from the multiple instances patterns above. The execution 
of the subsequent branch has to be blocked until the last instance has finished the 
execution. Listing 15 shows an example implementation with the WEE-DSL. In line 
2 a context variable is defined which indicates if a new instance of the activity has 
to be created. This is at least true for the first time. The loop in line 3 creates a 
new instance of activity a (line 5) as long as the context variable create-instance is 
true. The context variable create-instance is set by an external service (line 7) which 
defines if another instance of activity a has to be created. As the call of the external 
service is not part of the parallel execution, it is independent from the execution of 
the activity instance. Therefore it can determine the creation time for each activity 
instance. Multiple instances can be created parallel or one after another by blocking 
the service call until an instance has finished execution. 

LISTING 15: Multiple Instances without a Priori Run-Time Knowledge 

1 parallel : wait do 

2 context : create_instance => true 

3 cycle (" @create_instance" ) do 

4 parallel-branch do 

5 activity :a, : call , endpointl 

6 end 

7 activity : decide , : call , endpoint2 do | result | 

8 @create_instance = result 

9 end 

10 end 

11 end 

X Static Partial Join for Multiple Instances. The static partial join for multiple in- 

Z>Z> stances forwards the thread of control to the subsequent branch as soon as a given 

^ amount of instances finished execution. Other, still running instances, have to be com- 

pleted to re-enable the pattern but the result of these instances is withdrawn. The 
WEE does not support this pattern as it can only join all finished instances or abort 
instances which are no longer necessary. There are two variants of this pattern: The 
Canceling Partial Join for Multiple Instances pattern is analogue to the canceling par- 
tial join pattern described above. Other than the merge of branches, the canceling 
partial join for multiple instances pattern joins a given number of instances. The num- 
ber of instances can be determined at design time or before the first instance is created. 
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Listing 16 shows how to implement this pattern with the WEE-DSL. Multiple parallel- 
branches (and therefore multiple instances of activity a) are created by the loop (line 
3 to 10). As each paralleLbranch belong to the parallel-hlock defined in line 1, the 
number of paralleLbranches (and therefore the number of instances) that have to be 
completed can be defined here. The parallel-constTuct forwards the thread of control to 
the subsequent path as soon as the given mimber of paralleLbranches has completed. 
The nolongemecessary-signal is sent to unfinished paralleLbranches. 

LISTING 16: Canceling Partial Join for Multiple Instances 

1 parallel : wait => 1 do 

2 context :x => 3 

3 cycle ("@x^=^0" ) do 

4 activity : countdown , : manipulate do 

5 @x -= 1 

6 end 

7 parallel-branch do 

8 activity :a, : call , endpointl 

9 end 

10 end 

11 end 



The Dynamic Partial Join for Multiple Instances pattern provides the most flexibility 
when dealing with the merge of multiple instances. New instances can be created as 
long as the last instance has not finished. The number of instances depends on the 
execution progress or external information. After an instance has been executed, the 
thread of control can be passed to the subsequent branch. All other running instances 
are then withdrawn. The WEE does not support this pattern as the number of instances 
which have to be completed must be known at the first instance creation. 



3.5 Cancellation and Force Completion 

Cancel Task &i Cancel Case. The workflow instance is aborted and removed from 
execution. The cancel task pattern and the cancel case pattern are distinguished by 
the option when the cancellation is possible: The cancel task pattern specifies that the 
cancellation is possible at a specific activity. This activity and further also the workflow 
instance is aborted. The cancel case pattern allows to abort a workflow instance not 
only at the point of the execution of an activity but for the whole execution of the 
instance. The WEE does not distinguish between these patterns. It allows to stop the 
execution at any point during execution. The controller of the workflow instance has 
the possibility to send the stop-signal at any time. If a ca/^-activity is executed, the 
execution is delegated to the handler wrapper. Therefore the WEE cannot guarantee 
that the activity is aborted. The WEE can only inform the handler wrapper that it 
should stop the execution. The handler wrapper is then responsible to decide whether 
the service call can be aborted or not. This is important as the immediate abortion 
may lead to an inconsistent state or cannot be done without sanction which has to be 
avoided by the handler wrapper. 

Cancel Region. Other than the cancel task and cancel case pattern, the cancel region * 
pattern may not lead into the cancellation of the workflow instance. If an active branch 
(or parts of it) is outside a cancel region, this branch is unaffected by the cancellation. 
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The cancel region pattern defines a set of activities (which may be located also in 
different branches). Activities which are in the process of execution within this area 
are aborted when the cancel region pattern is activated. Activities which are in the 
process of execution outside of tliis area stay unaffected. To implement this pattern 
with the WEE comes with some difficulties. The WEE cannot abort only parts of 
the execution. If the WEE receives the stop-signal from the controller, the workfiow 
instance is stopped. Therefore, also activities which should stay in the process of 
execution are affected, which is not the intention of the pattern. Even if the handler 
wrapper does not allow the abortion, the result of the service call will not be integrated 
into the workflow by the WEE. The handler wrapper will not even be asked to provide 
the result value. But the WEE will ask for a passthrough value which gives the handler 
wrapper the possibility to store the result and reuse it when the workflow is continued. 
The sequence diagram in Fig. 1 now shows how the cancel region pattern can be 
implemented by the WEE. After the handler wrapper receives the stop-call-signsd, the 
service call is continued unaffected and the result of the service call is stored. The 
passthrough-value (identifying the result for later use) is returned to the controller 
of the workflow instance. When the controller continues the execution, the thread of 
control is set to the activities outside of the cancel region. The handler wrapper is 
provided with the passthrough-value and can look up the stored result. Therefore the 
service call does not have to be repeated (which may be costly). 

99 Cancel Multiple Instance Activity. Multiple instances of an activity are executed 
within one workfiow instance. The cancel multiple instance activity pattern aborts 
the workfiow instance and subsequentially all active instances of an activity. Already 
completed instances of an activity arc unaffected. The WEE covers this pattern with 
the same procedure as the cancel case pattern. The WEE allows to stop a workfiow 
instance at any point during execution, therefore it is also possible to abort running 
instances of an activity. 

X Complete Multiple Instance Activity. Multiple instances of an activity are created. 

DTiring the execution of the instances, the pattern indicates that the subsequent branch 
has to be executed. Therefore, remaining instances are no longer executed and with- 
drawn. Already finished instances are synchronized and their results are integrated into 
the workflow. The thread of control is passed to the subsequent branch. The WEE 
docs not support this pattern. Although the WEE supports the manipulation of the 
thread of control, it is necessary to stop the execution before the manipulation can be 
done, which is not in the intention of the pattern. 

3.6 Termination and Triggers 

99 Implicit Termination. A branch terminates if no further control structures have to be 

executed. If all branches have terminate, the workflow instance is also terminated and 
the workflow execution is marked as completed successfully. Due to the block structure 
of the WEE-DSL, the implicit termination is inherent. 

99 Explicit Termination. The workflow instance is terminated as soon as a specifled point 
in the execution is reached. All remaining branches are canceled. The WEE allows the 
handler wrapper or the controller of the workflow to stop the execution at any point 
during the execution by sending the stop-signal. The same mechanism is provided to 
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4: stop 



^ 10: passthrough 
11: continue(passthrough) 



: HandlerWrapper 



2: handle_call 



5: stop_call 



6: passthrough 



9: passthrough 



12: handle_call(passthrough) 



14: return_value 



<- 



3: invoke 



« 



8: store_result 



3: lookup_result 



Figure 1: Cancel Region Pattern 

the workflow description. Listing 17 shows an example implementation. The activity 
in line 1 sends the stop-signal to the WEE. If the handler wrapper has still running 
service calls, the handler wrapper is ordered to stop them if possible. Other activities 
will not be started. In contrast to the implicit termination, the end state of the workflow 
instance is set to stopped. 

LISTING 17: Explicit Termination 

1 activity : stop , : manipulate do 

2 stop 

3 end 

4 activity : whatever , : manipulate do 

5 # will not be executed 

6 end 

Persistent & Transient Trigger. An activity is enabled by a trigger. The persistent 
trigger pattern is implemented if the trigger event is stored until the activity is scheduled 
for execution. The event enables the activity during any time in the workflow execution. 
The transient trigger enables an activity only when it is scheduled for execution. If the 
transient trigger event occurs before the activity is scheduled for execution, the event is 
withdrawn. An activity which has not been enabled by a trigger blocks the execution 
until a trigger event occurs or the workflow execution is canceled. The WEE does not 
support triggers directly. As the execution of a service call is delegated to the handler 
wrapper, the trigger logic can be placed there. The handler wrapper can block the 
execution until the trigger event occurs. The downside of this approach is that the 
triggering logic is not anymore in the workflow description. 



7 Iterations 



Arbitrary Cycles. The arbitrary cycles pattern allows unstructured loops. The thread 
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Figure 2: Arbitrary Cycles Pattern Example 

of control can be set back to a defined point in the workflow description. The defined 

point can be located within another arbitrary cycle. Fig. 2 shows an example of a of an 
arbitrary cycle. As the WEE-DSL has a block structure, the arbitrary cycles pattern 
can not be expressed directly. Instead, the WEE allows modification of the thread of 
control which can be used to simulate the behavior. Fig. 3 shows how a modified 
handler wrapper has to act to implement the pattern. Activity 1 and Activity 2 are 
performed normally as service calls. The next ca/Lser?;ice-mcssage is then interpreted by 
the handler wrapper. The decision if the thread of control has to be altered is based on 
the condition provided by the workflow description. If the condition is validated as true, 
the thread of control is set to the given position identifier. The necessary information 
can therefore be specified in the workflow description and is not hard-wired in the 
handler wrapper. Although this implements the arbitrary cycles pattern, a complete 
implementation of the handler wrapper may also take care of possible side-effects which 
can arise when dealing with parallel active branches. 

Structured Loop. An activity or a set of activities and control structures are executed 

repetitive. The loop can be top-controlled or bottom-controlled. In contrast to the 
arbitrary cycles pattern, a structured loop can be expressed in a block manner. The 
WEE-DSL directly supports the structured loop pattern with the cyc/e-element. This 
element implements the top-controlled loop. Bottom-controlled loops are not supported 
but can be expressed through a top-controlled loop with minor overhead. Listing 18 
shows a sample of a structured loop. 

LISTING 18: Structured Loop 

1 context : x 3 

2 cycle ("@x„>„0" ) do 

3 activity : countdown , : manipulate do 

4 @x -= 1 

5 end 

6 end 

Recursion. The execution of an activity results in the execution of a new instance of the 
overall workflow description that is currently executed. Each recursion has to have at 
least one exit condition. As the WEE does not has the concept of multiple instances, 
the recursion cannot be supported directly. Instead, a recursion can be seen as a normal 
service call which in turn invokes a new workflow instance. The implementation can be 
therefore done by the handler wrapper. 

3.8 Comparison to Other Engines 

When we compare WEE with other workflow engines, the boundaries of our execution engine 
become apparent. Our execution engine focuses on the control flow aspect of workflows. 
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handlerWrapper : HandlerWrapper 



: Service 



1 : call_service(activity1 ) 



3: call_service(activity2) 



5: call_service(arbitrary1, condition, positioQ^ 



alt) 



[true] 



7: stop 



8: position(position) 
9: start 



6: valii 



4: involve 



validate condition 



Figure 3: Arbitrary Cycles Pattern Implementation 

More precisely, wc even focus on a single thread of control within our execution engine 
(except parallel branches). 

Existing workflow engines on the other hand have to cover a much larger set of functions and 
do not only focus on the control flow aspect. They also provide support for data and resource 
handling, security, logging, repair strategies and much more. 

Table 1 shows a summary of the pattern coverage as described so far. 



Table 1: Workflow Patterns Coverage 
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Wohed et al. [4] created a pattern based evaluation of different open source workflow systems. 
The analysis of our pattern support above allows to compare the coverage of our execution 
engine with this evaluation. In contrast to Wohed ct al., we used a more detailed categoriza- 
tion with levels of support instead of just coverage. To allow a comparison, we assume that 
directly supported (99) is equal to "+", modified workflow (9) and handler/ external (*) are 
equal to "+/-" and orchestrated instances (x) refers to "-" as this is the least supported 
category. 

The results of the comparison (see Tab. 2) show that WEE, although minimal, covers a 
range of patterns that enables it to outperform several commercial solutions. We conclude 
therefore that converting workflow description languages to the WEE-DSL can be achieved 
with low effort. 
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Table 2: Support of Control Flow Patterns 
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4 Conclusion 

In this technical report we outlined the structure of our DSL as well as evaluated its the sup- 
plied vocabulary against existing patterns. Additionally we compared the results to existing 
products. 

We proved that our approach is well suited to serve as a bridging technology. We envision that 
WEE is the core of a new series of network based execution engines that take arbitrary work- 
flow descriptions (transformed to the DSL) and execute it providing superior transparency. 
We envision external modules for monitoring, repair and semantic rule checking to become 
common network based infrastructure that is shared process aware information systems. 
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